The keys e.g., for encryption or integrity protection that are generated by certain example embodiments described herein are suitable for sensor networks. An example of such a sensor network is illustrated in FIG. 1. Further information of sensor networks can be found in “Protocols and Architectures for wireless sensor networks”, Holger Karl and Andreas Willig. The sensors of FIG. 1 are e.g. geographically distributed by an aircraft and form a network. The sensor network comprises a plurality of sensors comprising means for collecting and exchanging data. The data collection typically implies gathering of environmental information such as temperature, air pressure, sound, video, still picture, and vibrations. The collected data may be exchanged between the sensors and is typically processed at a central point, wherein at least one of the sensors is required to have direct connectivity to that central point. Therefore, at least one of the sensors comprise relay means. A sensor comprising relay means is also denoted relay sensor. The relay sensors are indicated with crosses and non-relay sensors are indicated with circles in FIG. 1.
The relay sensors are able to transmit and receive information to/from non-relay sensors and they are also able to communicate with a central point in the sensor network. E.g., the relay sensor receives measurement reports from a plurality of non-relay sensors and forward this received information, in addition to its own measurement reports, to a central point in the network. The central point may be a base station of a cellular network, or a vehicle with an antenna that may forward the reports to a central unit for processing the information of the reports.
Sensors are in some cases, as illustrated in FIG. 1, randomly distributed in a geographical area, e.g., dropped from an aircraft. In this case, a “discovery” protocol is first run to determine the nearby sensors having relay capability and/or which sensors that should take the role of the relay sensor. Examples of discovery protocols may be found in the reference Karl and Willig above. This phase may also contain initial security handshakes, where non-relay sensors create secure connections to other (relay) sensors.
Alternatively, the sensors may be distributed in a more orderly fashion, in which case relay sensors are configured as appropriate. A typical example of this is in an apartment building where each apartment could be given a number of associated sensors, wherein at least one of the sensors is a relay sensor communicating with a central point e.g. associated with the building.
The security requirement for the communication in the sensor network depends on the type of sensor application, and the security requirement for the communication between the relay sensors and the non relay sensors requires typically less security than the communication between the relay sensors and the central point in the sensor network due to the short-range characteristics of transmissions from non-relay sensors. However, many applications require that the communication between the relay sensors and the central point be performed in a highly secure way. Certain example embodiments are best suited for the protection of communication between relay sensors and the central point (e.g., a base station), but does not exclude use also for the above mentioned inter-sensor communication.
A common technique for secure communication is to start a communication session by a “handshake” that negotiates or generates keys. However, in critical sensor applications, there is usually a wish for the party that receives data from the sensor to maintain “radio silence”, i.e., not to reveal the presence or location of the communicating party. A sensor may also want to limit the amount of signaling to conserve energy; transmitting one bit on the radio interface consumes as much energy as executing roughly 800-1000 local CPU instructions. Likewise, also listening consumes power. In many applications, it is also the case that a specific recipient of the data may be unknown to the sensor, e.g., in broadcast scenarios. Consequently, it can be assumed that the sensor needs to be able to produce the key on its own, and also somehow “hint” to authorized receivers which key it used in a secure and simple way. Therefore, the basis for the key material needs to be stored in the sensor from the beginning, e.g., during manufacture or configuration prior to deployment. A common way to generate new keys from such a basis is to apply a cryptographic function f to a master key Kmaster and to some random data:Ksession=f(Kmaster, RANDOM).
A first problem with this is that a small sensor may have no sufficiently good source of random data, and the RANDOM will in practice be a “counter” value or similar so that session keys are distinct. However, this degrades the quality of the keys. Another approach would be to useKnew=F(Kold),but this has the drawback that if a certain key is exposed e.g. due to cryptanalysis of the algorithm in which it is used, all future keys are exposed. In addition to this, common to both of the above approaches is that certain applications with very high security requirements simply forbid the cryptographic generation of keys in end-devices as inappropriate/not allowed. If for instance f is a function like the SHA1 hash or the AES algorithm, security of the above approaches relies on cryptographic assumptions, which may turn out to be false, i.e., security is purely heuristic. Applications with high requirements may in fact require a formal, mathematical proof of certain properties such as exact statistical distribution of the keys, which cannot be obtained by the methods just discussed.
Hence, due to the problems of key generation in the sensor and the desire to avoid unnecessary communication, the sensor may need to store a relatively large amount of pre-installed keys that were generated by high-security key generation device, which in turn is problematic due to the constrained environment of the sensor.